Good accessibility means that everybody, independent of possible disabilities, should have reasonably good access to the information and functionality on the website. Since more and more official information and functions are available on websites, the matter of accessibility has become increasingly important. Creating a website with reasonably good accessibility is not that very difficult, but it requires a good strategy and some discipline. Having a good publishing tool, that can manage content and presentation separately, makes it much easier. This section covers some of the most important aspects of accessibility.
Accessibility is not an isolated phenomenon. The complete picture, including design, functionality, services and delivery format, must be investigated. The effect of individual decisions must be compared with other requirements and decisions. Sometimes, requirements may be contradictive when regarding different accessibility aspects.
Each website should set its own ambition for accessibility. The implemented design and functionality must be adapted to those decisions. The accessibility level is much about making compromises, and it must be a continuouss process that follows the development of the website.
Basic accessibility guidelines
Following the basic requirement, the website is guaranteed to at least fulfill the most basic requirements for good accessibility.
- Select a code standard (i.e. XHTML 1.0 or HTML 4.01) and follow that standard rather than adjusting to specific web browsers. Rely on the fundamental (standardized) technologies, and avoid plug-in programs, Java or JavaScript.
- Have a well defined start page to which it should be easy to navigate from anywhere at the website. The start page should describe the purpose and content of the website.
- Create a consistent and logical menu structure. Focus on the information that is available rather than the organization that provides it. Supply web maps to overview the website, and breadcrumbs on the pages to detect the current location in the information structure.
- Create a design that is independent on screen size or window size. The layout should be floating or elastic rather than static. Do not use frames or tables to define the screen layout. Use consistent schemas for color, design and layout. Style sheets (CSS) are very useful. A certain area should be consistently used for certain kinds of information.
- Create good readability by selecting fonts that are easy to read, and keep good proportions between text blocks and spaces. Use colors and contrasts that make reading easy. Remember that some people have difficulties to differ colors (primarily red and green), and that some people must have high contrasts.
- It should be possible to personalize the presentation of the content. The most important thing is the possibility to adjust the colors, spacing and font size on the whole site. To allow this it is necessary to apply style sheets.
- It should be easy to detect where there are links and additional information. Use underlined links and keep track on already visited pages. Make sure that active (selected) links are visibly indicated. If an area contains links, use the largest possible area for each link.
- Use the standard functionality in the web browsers. The “Back” button should work. Use the built-in printing functionality of the web browser rather than customized “printer-friendly” pages.
- Design the pages to allow keyboard navigation. There are standardized shortcut commands that are used by tools for disabled. It should be possible to skip sections to further improve navigation
- Tables should be avoided as much as possible. They should only be used for tabular data, and then column headers, rows and columns should be described. It is very easy to make tables that ruin the accessibility.
- Forms should be easy to understand and there should be clear and concise instructions. Group fields that belong together. Make sure that the fields are in the correct tab order and that the size of the fields match the expected amount of data. Keep the number of mandatory fields to a minimum. Have descriptive labels connected to each field and use standardized field names.
- Make sure the error messages are understandable, polite and be of help for the user to get around the problem. The message should be clearly visible and if there are several messages they should be together.
- Avoid automatic redirection to external pages. Any link leading to page outside the website should be marked as such.
- Avoid moving images, animations, blinking and other things that are distracting.
- Test the code quality! There are several validation tools available that measures the generated code. They will improve and document your level of accessibility.
- If you have functionality that uses plug-in programs or JavaScript you should have a fallback solution for those users that don't have support for plug-ins or Javascript.
Accessibility standards
There are no definite standards for accessibility, but there are several guidelines to set some kind of accessibility standard. Some of the rules are technical and can be checked by validation software. Other rules have to be determined manually by humans.
The international recommendations are usually based on the “Web Content Accessibility Guidelines” provided by WAI/W3C. The requirements are sometimes easily measured with some validation tool, but some of them can only be determined by investigation. Some requirements may be contradictive, leading to a decision on technology and implementation. They have three priority levels on requirements
- Issues that must be satisfied
- Issues that should be satisfied
- Issues that may be addressed
In Sweden, Verva has published “Vägledningen 24-timmarswebben” (in Swedish) which describes requirements on websites for Swedish governmental organization. It basically follows the “Web Content Accessibility Guidelines” provided by WAI/W3C, but contains some special rules and adaptations. They too have three steps to determine the conformance level. There is however no absolute requirements on what these websites should be able to do. It is up to each organization to determine their ambition level and interpretation of the guidelines.
Nowadays, any website that claims to have "good accessibility" should meet all requirements on the first level ("A") and most of the requirement on the second level ("AA").
Content Studio accessibility
Content Studio is a platform that gives editors great freedom to express themselves. Therefore, the use of Content Studio (or any other publishing platform) will not guarantee good accessibility in all scenarios.
Content studio components
Much of the website presentation is managed by components. They are designed to support design that can provide good accessibility. The default settings are normally set to provide good accessibility. In this context, good accessibility only refers to the technical aspects such as attributes in the generated code. Design aspects, such as layout and color schemes, must always be managed separately.
From an accessibility perspective, there are a number of components or technologies that must be handled with care. They may allow generation of code with poor acessibility if wrongly used.
Component | Description |
---|---|
Webitor |
The webitor is an editor to create document content. Some of the features allows
writers to create content which can destroy the accessibility of an otherwise well
designed website. To accomplish good accessibility, the writers are often only allowed
to use a limited set of features and classes.
The most infamous is table insertion, since tables easily are made inaccessible. Especially if they are used for layout rather than tabular data. The following features are often disabled: Tables, Font style, Font size, Font color, Background color |
Search result for categories (et.al) | This component, as well as some others, generates a table of data. Some attributes, such as TARGET must be used carefully to avoid generating improper code. |
Support for writers and editors
The Content Studios user interface can support writers and editors in their work in many ways. The automatically generated code is automatically validated to follow that standards of the given document type. The generated code can always be manually validated for a whole document. This is particularly important if the writers are allowed to manually add code, rather than using the standardized components.
Writers and editors often provide content only for a small part of a web page, and then it is important that the content matches the rest of the web page. To ensure that the final content is valid, it is possible to preview the content in different context. The content can be validated for each context separately.
It is possible to configure Content Studio to deny publishing of content if the generated code is invalid. Even without that setting, Content Studio will give warnings for non-validating code. There can also be warnings for measurable accessibility errors, such as images without ALT attribute text.
More information on accessibility, CSS and XHTML
- The CSS standard by W3C: http://www.w3.org/Style/CSS/
- The HTML standard by W3C: http://www.w3.org/MarkUp/
- The XHTML standard by W3C: http://www.w3.org/TR/xhtml1/
- The XHTML standard by W3C: http://www.w3.org/TR/xslt
- Homepage of Verva: http://www.verva.se/
- Web version of the accessibilty guideline from Verva (Vägledningen 24-timmarswebben): http://www.verva.se/web/t/Page____1154.aspx